home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970104-19970326 / 000174_news@columbia.edu _Sun Feb 2 19:23:05 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA03948
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sun, 2 Feb 1997 19:23:05 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA21529
  7.     for kermit.misc@watsun; Sun, 2 Feb 1997 19:23:04 -0500 (EST)
  8. Path: news.columbia.edu!panix!news.mathworks.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!su-news-hub1.bbnplanet.com!newsout1.alt.net!news1.alt.net!nntp1.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!usenet
  9. From: Clark Briggs <Hugh.C.Briggs@jpl.nasa.gov>
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit Protocol Overview
  12. Date: Sun, 02 Feb 1997 16:07:32 -0800
  13. Organization: Jet Propulsion Laboratory - Pasadena CA
  14. Lines: 65
  15. Message-ID: <32F52C44.7A9F@jpl.nasa.gov>
  16. References: <32F26B93.63E3@jpl.nasa.gov> <5ctsq5$dpk@watsun.cc.columbia.edu>
  17. Reply-To: Hugh.C.Briggs@jpl.nasa.gov
  18. NNTP-Posting-Host: sailor.jpl.nasa.gov
  19. Mime-Version: 1.0
  20. Content-Type: text/plain; charset=us-ascii
  21. Content-Transfer-Encoding: 7bit
  22. X-Mailer: Mozilla 3.01 (WinNT; I)
  23. Xref: news.columbia.edu comp.protocols.kermit.misc:6523
  24.  
  25. Great answer Frank! Thanks.  Im not sure what I can do next because I
  26. dont have
  27. easy access to the one breadboard we have.  I think you're right, the
  28. lack of 
  29. ack/nak and crcs makes it pretty clear its not Kermit.  Probably just
  30. uses Kermit
  31. on the workstation to send a particular binary stream down the serial
  32. line.
  33.  
  34. clark
  35. ps, further comments embedded near Frank's questions below
  36.  
  37. Frank da Cruz wrote:
  38. > 
  39. > In article <32F26B93.63E3@jpl.nasa.gov>,
  40. > Clark Briggs  <Hugh.C.Briggs@jpl.nasa.gov> wrote:
  41. > : We are considering an embedded processor that seems to use kermit
  42. > : over its serial port to load its boot image.  We can see the
  43. > : ROM code that is doing this and standard practice is to use
  44. > : a Unix Kermit on a workstation for the boot host.
  45. > :
  46. > Do they give you directions for this?  What are the directions?
  47. My phone conversation with the engineer that has the machine didn't get
  48. beyond
  49. "you just use kermit..."  We will try to sit with him and watch.
  50. > 
  51. > : Where can I find a short text description of the Kermit protocol
  52. > : to see if this processor is really doing a kermit thing?
  53. > :
  54. > The Kermit protocol specification is in a book, but all you need to
  55. > is whether it's Kermit, right?  
  56. yes
  57. > Why don't you just capture a bit of
  58. > it and post it or send it to kermit-support@columbia.edu and we'll
  59. > tell you just what it is.
  60. probably wont impose on you for this, I like your idea below to test
  61. with
  62. a kermit packet.  Plus, when I watch a session, I think that will be
  63. enough.
  64. > 
  65. > : I have been told that this processor only loads binary files,
  66. > : looks for 3 simple intro facts (where to load in memory, where to
  67. > : begin execution, and how long is the load-image-file) followed
  68. > : by the load-image-file-in-binary.  It is further said that there
  69. > : are no checksums or ack/nak stuff in the ROM code.
  70. > :
  71. > Well that's not Kermit -- Kermit always has checksums (or CRCs) and
  72. > ACK/NAKs -- otherwise how would it detect and recover from errors?
  73. > 
  74. > : Can this be a valid (simple, minimal, whatever) kermit protocol?
  75. > :
  76. > Not as you describe it.
  77. > 
  78. > Try this: Connect your terminal emulator to this thing, and type:
  79. > 
  80. >   <Ctrl-A>7<Space>SXXXXXXXXXXXXXXXXXXXXX<Carriage Return>
  81. > 
  82. > This is a Kermit packet that contains junk and a bad checksum.  If
  83. > Kermit protocol is reading this packet, it should respond with:
  84. > 
  85. >   <Ctrl-A><Space>N3<Carriage Return>
  86. > 
  87. > Which is a NAK.
  88. > 
  89. > - Frank